This chapter introduces two techniques for documenting business processes- Data Flow Diagrams (DFD's) and System Flowcharting (SFC). It discusses how to read these documents, their purpose, and guidelines for creating DFD's and SFC's from narratives (see discussion)
Data Flow Diagrams (DFD):
Definition: graphical representation of a system that depicts the following elements:
system components (Business Processes - Logical and Infrastructure - Physical)
data flow (between system components and data storages)
data sources, destinations and storage (Data is stored when there is a delay between processes)
Types of Dataflow Diagrams (define and explain the differences):
Context- this view is considered a top-level or least detailed diagram of an information system. It depicts [exactly] one system (process) and all of its activities as a single bubble; it also depicts the data flows into and out of the system and into and out of the external entities, e.g. the cash receipts process is modeled simply as the customer makes a payment into the process and then we take the deposit to the bank. (p.101) The process is defined using a noun, i.e. cash receipts process. Also, the diagram includes no data storage symbols, because storage happens within the process. Must contain at least one external entity, and at least one source and one sink of information flow.
Physical -- this view emphasizes entities over processes (emphasized in logical dfd's). The Physical DFD focuses on where and how data is physically processed as well as the person responsible for carrying out a system's processes. As such, bubble symbols contain nouns such as sales clerk, cashier and bookkeeper to describe the "who" in the system; dataflows depict the path by which data travels from one entity to another. Physical DFDs focus on system infrastructure - the downfall - we don't know what was done, but we do know how, where, and by whom the system processes are performed.
Logical -- this view emphasizes the processes and is best utilized over the the long-term (how we physically move and/or store data may change, but what we're doing usually doesn't). This system uses verbs to label bubbles and concentrates on activities, rather than infrastructure. This is why a logical DFD is more useful than a physical DFD. We use a logical DFD to document information systems (what tasks the system is doing) without having to specify how, where or by whom the tasks are accomplished. Concentrates on the business processes of the system and not the infrastructure of the system.
Both diagrams are essential to understanding an entire system.
Benefits of DFD's
Uncover misunderstandings of system processes by creating abstract and get people together to walk through.
Help communicate analyst system understanding to management/end users.
Help to take the system out of context, and focus on what is going on and look at pictures and clearly make sure the internal control takes place.
Levels of Dataflow Diagrams:
Context -- Top level, least detailed diagram of an Information System, whereas the DFD has been reduced to Internal processes (the bubble in the center), external sources/destinations, and the data flows between them. For example, a context level representation of the cash disbursements process would contain two external entities, a vendor and the bank with a bubble representing the cash disbursements process. Data flows would be reflected to show withdrawals from the bank transformed into a vendor payment. A context level diagram contains: one process (cash disbursements), at least one entity (bank), and at least one source and one sink. A source is an input to the process and a sink is an output from the process to an entity.
Level-0 -- Top level view of a physical or logical DFD. It is called this because the bubbles have the format x.0. This is the level below context. It is an "explosion" of a context level diagram. Notice that this level contains the same inputs and outputs as the context level diagram, as such we would say that they are "balanced".
Level-1 -- Level below Level-0 (each bubble will have x.1). Drills down another level from Level-0 to give us more detail on the individual components of the Level-0 process. The entity boxes appearing in the context level and level-0 diagrams usually do not appear in diagrams below level-0.
Level-x (How low can you go?) -- We can drill down as many levels as necessary, until we have documented and understood the system adequately. This successive "drilling down" is called top-down partitioning. The lowest level of the DFD is known as the functional primitive.
Balanced Data Flow Diagram set -- Only Balanced sets of DFDs are considered correct. This is when the external data flows (in and out of the system) are the same....in other words, if you have 1 data flow from External Source A and 2 data flows out to Process B and External Source B in one diagram, you have to have the same thing in the other diagram (although the level of detail to GET to that point may be much greater and the diagram consequently much more elaborate). An example of determining whether a set of data flow diagrams are balanced occurs when one compares a context diagram to a level 0 diagram for the same system and verifies that the external data flows in and out of the system are the same for both of these diagrams. If they are the same, then the data flow diagram sets are balanced. Another way to make sure that your DFD is balanced is by counting the number of inputs and outputs on the context diagram and making sure you have the same number on the other DFD diagrams.
Data Flow Diagram Symbols:
Bubble (Physical or Logical) -- Entity or process within which incoming data flows are changed into outgoing data flows. Represents Entity in a physical DFD and a Process on a logical DFD.
Arrow -- pathway for data, dataflow among components of DFD. Data flow either starts with a process or ends with a process because processes initiate data flow and data flows are also a result of business processes.
Box -- Sources and destinations of data. The box is an external entity -- something outside the system. Can be a source of data or a sink for data.
Open-ended Rectangle -- a place where data is stored. This may represent only a part of a larger database.
Preparing Systems Documentation:
Preparing Data Flow Diagrams
Uses:
1. Document an existing system
2. Develop a new system
The Narrative
The narrative is the verbal representation of the process or system of interest. The narrative is very important. It should include every single step in the process in the order in which it occurs; no step is too small or insignificant. The narrative will become the source for the entities and activities table, which is the next step in the design of the system. Label the paragraphs and the lines when reading through the narrative to help in preparing data flow diagrams and flowcharts.
Table of Entities and Activities (describe the steps for creation):
Basic Table:
1. Start with narrative and underline each ACTIVITY being performed and circle each ENTITY that performs the activity. NOTE: Remember activities are verbs and entities are nouns. Include every entity mentioned in the narrative, no more and no less.
2. List each activity in the order it is performed, regardless of the sequence in which it appears in the narrative. The list should include the activity along with the name of the entity that performs the activity. After all activities are listed, consecutively number each activity.
3. Next, draw the context diagram. This will consist of one circle (bubble) in the center of the page and boxes for each external entity. External entities are those that do not perform any information processing activities. Go through the list you created in #2 and determine witch activities are not information processing activities. Any entity that is not performing at least one information processing activity is an external entity and will be included in a separate box outside the main bubble. Next go through the narrative again to identify any other entities that were not originally pulled out. Check these for information processing activities and if they lack information processing they are external entities. Make sure to follow the DFD guidelines explained in the book. They will help with creating the context diagram as well as the other data flow diagrams.
NOTE: Do not make assumptions about additional entities or activities (DFD guideline 3), except that if a data store is logically necessary, include a data store in the diagrams (DFD guideline 6), whether or not it is mentioned in the narrative.
Drawing the Context Diagram
The context diagram contains one circle, a minimum of two squares (at least 1 source and 1 sink), and lines representing data flows. The circle represents the process being modeled and is labeled as such. The circle (process) will include any entity that performs one or more information processing activities (DFD guideline 1). The squares represent the entities that are external to the process, but who either provide input or receive output. There will be one square for each entity, and each square will be labeled with its entity's name. The entities (squares) will be connected to the process (circle) with lines representing data flows; the lines should be clearly labeled as to what the flow is, i.e. payment, deposit, etc...
Information processing activities are one of the things that distinguish internal entities from external entities. For an activity to be considered an information processing activity, it must retrieve data from storage, transform data, or file data. Only information processes can retrieve and process data, not external entities such as sources or sinks.
Drawing the Current Physical Data Flow Diagram
It is important to start by placing the squares (entities) around the outside of the page. Typically they are the same as the ones from the context diagram. To keep the diagram balanced be sure to label the same inputs and outputs from the context diagram, leaving the middle of the page open. Each internal entity becomes a Circle in the middle of the page. Follow this by going through all data flows and drawing the correct arrows to show the process path.
Drawing the Current Logical Data Flow Diagram
The current logical DFD portrays the logical activities performed within the system. (p. 117)
The current logical DFD begins with a Level 0 DFD (see above) and should adhere to these guidelines, according to the text:
Using the infomation from the entity and activity table:
1. DFD Guideline 7: Group activities if they occur in the same place and the same time.
2. DFD Guideline 8: Group activities if they occur at the same time but in different places.
3. DFD Guideline 9: Group activities that seem to be logically related. (p. 117)
4. Name each group according to the logical activities within the group, e.g. process payment, prepare deposit, etc...
5. Annotate the E&A table by placing the names of the processes determined in Step 4 next to their grouped activities; additionally, number the groupings in the order in which they occur in the process, using 1.0, 2.0, 3.0, and so on.
6. Drawing the DFD
a. draw the external entities
b. draw and label the flows to and from the external entities
c. draw the internal bubbles (processes) and flows (p. 119). For clarity and easiness to read, use between five and seven processes to depict the system.
Data should flow from lower processes (ex. 1.0) to higher processes (ex. 4.0) and not vice versa.
Preparing Systems Flowcharts
Create columns for the entities (1 column for each external entity and 1 for each internal entity). Only pick the entities that actually do some information processing. Start the flowchart, normally, from the top left corner. Flowcharts are made to be read from top to bottom and from left to right. Manual processes are not needed for the sending or storing of documents. The sending of documents should be obvious based on the movement of the document and the storing of documents should be easily understood by the flow and the data store symbol. You do not want to clutter the flowchart with more processes than needed.
Documenting Information Systems:
This chapter introduces two techniques for documenting business processes- Data Flow Diagrams (DFD's) and System Flowcharting (SFC). It discusses how to read these documents, their purpose, and guidelines for creating DFD's and SFC's from narratives (see discussion)Data Flow Diagrams (DFD):
Types of Dataflow Diagrams (define and explain the differences):
Benefits of DFD's
Levels of Dataflow Diagrams:
Data Flow Diagram Symbols:
Preparing Systems Documentation:
Preparing Data Flow Diagrams
Uses:1. Document an existing system
2. Develop a new system
The Narrative
The narrative is the verbal representation of the process or system of interest. The narrative is very important. It should include every single step in the process in the order in which it occurs; no step is too small or insignificant. The narrative will become the source for the entities and activities table, which is the next step in the design of the system. Label the paragraphs and the lines when reading through the narrative to help in preparing data flow diagrams and flowcharts.Table of Entities and Activities (describe the steps for creation):
Basic Table:1. Start with narrative and underline each ACTIVITY being performed and circle each ENTITY that performs the activity. NOTE: Remember activities are verbs and entities are nouns. Include every entity mentioned in the narrative, no more and no less.
2. List each activity in the order it is performed, regardless of the sequence in which it appears in the narrative. The list should include the activity along with the name of the entity that performs the activity. After all activities are listed, consecutively number each activity.
3. Next, draw the context diagram. This will consist of one circle (bubble) in the center of the page and boxes for each external entity. External entities are those that do not perform any information processing activities. Go through the list you created in #2 and determine witch activities are not information processing activities. Any entity that is not performing at least one information processing activity is an external entity and will be included in a separate box outside the main bubble. Next go through the narrative again to identify any other entities that were not originally pulled out. Check these for information processing activities and if they lack information processing they are external entities. Make sure to follow the DFD guidelines explained in the book. They will help with creating the context diagram as well as the other data flow diagrams.
NOTE: Do not make assumptions about additional entities or activities (DFD guideline 3), except that if a data store is logically necessary, include a data store in the diagrams (DFD guideline 6), whether or not it is mentioned in the narrative.
Drawing the Context Diagram
The context diagram contains one circle, a minimum of two squares (at least 1 source and 1 sink), and lines representing data flows. The circle represents the process being modeled and is labeled as such. The circle (process) will include any entity that performs one or more information processing activities (DFD guideline 1). The squares represent the entities that are external to the process, but who either provide input or receive output. There will be one square for each entity, and each square will be labeled with its entity's name. The entities (squares) will be connected to the process (circle) with lines representing data flows; the lines should be clearly labeled as to what the flow is, i.e. payment, deposit, etc...
Information processing activities are one of the things that distinguish internal entities from external entities. For an activity to be considered an information processing activity, it must retrieve data from storage, transform data, or file data. Only information processes can retrieve and process data, not external entities such as sources or sinks.
Drawing the Current Physical Data Flow Diagram
It is important to start by placing the squares (entities) around the outside of the page. Typically they are the same as the ones from the context diagram. To keep the diagram balanced be sure to label the same inputs and outputs from the context diagram, leaving the middle of the page open. Each internal entity becomes a Circle in the middle of the page. Follow this by going through all data flows and drawing the correct arrows to show the process path.Drawing the Current Logical Data Flow Diagram
The current logical DFD portrays the logical activities performed within the system. (p. 117)The current logical DFD begins with a Level 0 DFD (see above) and should adhere to these guidelines, according to the text:
Using the infomation from the entity and activity table:
1. DFD Guideline 7: Group activities if they occur in the same place and the same time.
2. DFD Guideline 8: Group activities if they occur at the same time but in different places.
3. DFD Guideline 9: Group activities that seem to be logically related. (p. 117)
4. Name each group according to the logical activities within the group, e.g. process payment, prepare deposit, etc...
5. Annotate the E&A table by placing the names of the processes determined in Step 4 next to their grouped activities; additionally, number the groupings in the order in which they occur in the process, using 1.0, 2.0, 3.0, and so on.
6. Drawing the DFD
a. draw the external entities
b. draw and label the flows to and from the external entities
c. draw the internal bubbles (processes) and flows (p. 119). For clarity and easiness to read, use between five and seven processes to depict the system.
Data should flow from lower processes (ex. 1.0) to higher processes (ex. 4.0) and not vice versa.
Preparing Systems Flowcharts
Create columns for the entities (1 column for each external entity and 1 for each internal entity). Only pick the entities that actually do some information processing. Start the flowchart, normally, from the top left corner. Flowcharts are made to be read from top to bottom and from left to right. Manual processes are not needed for the sending or storing of documents. The sending of documents should be obvious based on the movement of the document and the storing of documents should be easily understood by the flow and the data store symbol. You do not want to clutter the flowchart with more processes than needed.